1. Field of the Invention
This invention pertains generally to computer products that have encryption technology as part of the product being sold. More particularly this invention is directed to a system and method for selecting a particular level of cryptographic support when the base product provides multiple levels of cryptographic support.
2. The Prior Art
Cryptographic packages as offered in computer systems, or as part of a component sale, are well known. Cryptographic packages may consist of several types, including two-way encryption techniques based on DES, 3DES, and RC4; asymmetric encryption techniques used for public key encrypting such as RSA, DH, and DSA; and, authentication techniques based on SHA-1 and MD5.
All such solutions share a substantial number of components, be they implemented in software or hardware. Because all the cryptographic packages share so many components in common, they are implemented and offered as a single package from which one chooses which components, or level of cryptography, to enable or use. In a software implementation, the desired cryptographic support may be compiled during a system build or selectively invoked using various system initialization or configuration parameters. In a hardware implementation a chip is typically enabled for a certain type of cryptographic support during system initialization using system boot parameters.
The problem is how to provide a high degree of reliability on enabling or disabling certain cryptographic features (capabilities). This is important for several reasons. One reason is export control. Some countries are not allowed to receive certain levels of cryptography. Another reason is only allowing customers to use what they paid for. Since cryptographic implementations of all types have multiple levels of support built into them, enabling only some features in a highly reliable manner is a critical concern.
Software implementations have the advantage that they can be custom built. However, that solution also has overwhelmingly severe disadvantages. First, all known implementations of cryptographic features are notoriously compute intensive. If the cryptography in use is software based, and the system is to be used for anything other than just encryption and decryption, system performance will always degrade to a very noticeable degree. This is unacceptable, so software solutions are not as common except in dedicated security systems. In addition to poor performance, using different builds for different cryptographic support results in severe logistical problems as the number of releases grows. Thus, the only pragmatic solution is to use some kind of system initialization parameter.
Hardware implementations are far more common than software solutions because of their speed. Hardware implementations of cryptographic functions result in almost no discernable downgrade in overall system performance. Unlike software implementations, a hardware implementation will always have all the normally desired cryptographic capabilities built into one chip. Thus, the only solution for selecting a subset of those capabilities lies with selectively enabling or disabling them during system initialization.
Setting aside the software solution involving selective builds due to its high cost (extremely difficult logistical support, resulting in high costs, associated with different builds for a large number of small groups of customers), it is readily seen that the best commercially viable solution involves enabling or disabling cryptographic features using some kind of system initialization or configuration data.
Up to now, there has been little protection from clever people doing reverse engineering on a product to find out how and where system initialization parameters are kept and used. Thus, there is a real need for any method or system that would provide better protection of cryptographic enabling or disabling features that must be used to configure systems according to the country sold, or a customers purchasing decision.